Add a memory map of VRAM #544
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This makes it more prominent, and also more useful
It is slightly dynamic, relying on a fuckton of pre-generated elements and a `display:` CSS rule. This generates a **monster** SVG (5108 lines), which is not great. The file could be slimmed down tremendously by making use of `<use>` elements (e.g. `<use href="#tile_block">` in six places), but this is incompatible with the CSS trick used (then the `<text>` elements cannot be all positioned in the same place in the parent). It may be more reasonable to use some JS for this, instead of this pure-CSS hack.
The SVG went from 929744 to 9249 bytes!! Meanwhile, we only have 29 sloc of JS in ~3 KiB, which perform very little processing. Definitely a worthwhile tradeoff. The SVG being significantly deflated also makes it easy to process by hand, removing the need for a generator script and simplifying the build.
Rangi42
reviewed
Feb 18, 2024
Co-authored-by: Sylvie <[email protected]>
Rangi42
reviewed
Feb 18, 2024
Rangi42
reviewed
Feb 18, 2024
Co-authored-by: Rangi42 <[email protected]>
|
This last commit moves the JS file from stand-alone to being contained within the SVG itself; this makes the SVG fully interactive even when viewed stand-alone instead of within Pan Docs. |
Rangi42
suggested changes
Feb 18, 2024
Rangi42
suggested changes
Feb 18, 2024
ISSOtm
commented
Feb 18, 2024
Co-authored-by: Sylvie <[email protected]>
Rangi42
approved these changes
Feb 18, 2024
avivace
previously requested changes
Feb 18, 2024
Co-authored-by: Antonio Vivace <[email protected]>
avivace
approved these changes
Feb 20, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #533.
The hand-written SVGs return! (Sorry, Antonio... :P)
The SVG was originally (see 966b0d1) generated automatically from a Python script. At that point, it was fully self-contained (no JS required for interactivity)... at the cost of being just shy of one megabyte.
Considering this was ridiculously large, and visibly taxing on the browser, the SVG was entirely overhauled to move the interactivity from a ****ton of elements and a bit of CSS, to only a bunch of elements and a bit of JS. (This was never fully realised, thus never committed.)
The result was still very large, so I started making use of the
<use>element, which allows duplicating elements without copy-paste—perfect for these massive grids! (And chances are, the browser may be able to optimise that. Idk.) This was impossible with the old CSS-only design, due to it being based on some elements having the same position within the parent (which<use>inherently precludes.)Unfortunately,
<use>is also very finicky with regards tomouseover/mouseenterevents (especially the former), so the final implementation (fdbf322) may raise some eyebrows among JS devs. I tried to be clean, but I'm only an amateur in that field... :D